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(57) Abstract: A meihdd and apparatus is provided to allow telephony or other types of media communications and services to be 
provided for a device (24) having a private network address thai resides behind a firewall and network address and port translation 
(NAPT) module (which is not aware of the underlying protocol for the communications and services). Examples of the underlying 
protocol includes the Session Initiation Protocol (SIP) and Real-Time Protocol (RTP). A path through the firewall and NAPT module 
is defined by use of keep-alive messages communicated through the firewall and NAPT module. Addresses that are allocated by 
the firewall and NAPT module are associated with the device (24) for both signaling and media communications. A feature of the 
firewall that enables the provision of telephony and media communications through the firewall that is protocol-unaware is that the 
firewall allows responses to messages initiated by the device back through the firewall. 
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Providing Telephony Services To Terminals 
Behind A Firewall And/Or! Network Address Translator 

Technical Field 

The invention relates generally to providing telephony services to terminals behind a 
firewall and/or a network address translator. 



Background 

Various forms of communications can be performed in packet-based networks, such 
as electronic mail, web browsing, file transfer, and so forth. With the increased capacity and 
reliability of packet-based networks, voice communications (along with other forms of real- 
time, interactive Communications) have also become feasible. In such communications, voice 
and other real-tin ie data are Carried in packet's that are sent across the network. 

Standards ; have been;proposed for voice and multimedia communications over packet- 
based networks. jDne such standard is the H.323 Recommendation from the International 
Telecommunication Union (ITU). Another stkndard for voice and multimedia 
communications is the Session Initiation Protocol (SIP), as developed by the Internet 
Engineering Task Force (IETF). Generally, H.323, SIP, and other control protocols are used 
for negotiating session information to coordinate the establishment of a call session. Once 
negotiation setup has been completed, packetized media (including voice or other forms of 
real-time data) cab flow between endpoints. A media transport protocol, such as the Real- 
Time Protocol (R^TP), is used for conveying packetized media between the endpoints. 

Various issues are associated with communications over packet-based networks. One 
is the dwindling supply of network addresses, such as Internet Protocol (IP) addresses. To 
address this problem, network address translation (NAT) is provided to enable address 
translations between public and private networks. By reusing a pool of private addresses in 



different private networks, t 



le virtual supply of network addresses is extended. Another 



concern df packet-based communications is security. Once a network address of a specific 



node is known, tliis network address can be used as routing information to gain illegal access 

to the node and all of its resources. Network address translation can be used to hide network 

i 

addressejs of nodes to protect such nodes. 

Also, to prevent unauthorized access of a private network, a firewall is placed 
between 'the private network and a public network. Thus, in a typical aiTangement, nodes and 
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terminals on a private network are connected behind a node that includes both a firewall and 
a network address translator (NAT). Collectively, such a node can be referred to as a 
"firewall and NAT module" or "firewall and NAT device." 

Generally, to offer telephony services to terminals or clients that reside behind a 

i ; 

firewall and NAjT module, some modification typically is needed of the firewall software. 

One issue is that .a firewall does not allow unsolicited connections from a system or device 

outside i private network to nodes or devices on the private network. Another issue is that, 

because of the presence of a NAT, a network address allocated to a terminal (for 

communicating iearer traffic packets) by the NAT is not known until the network address 

! i { ; 

translation actually occurs. Note that the address used by the terminal for call session setup 

signaling (control signaling) may be different for the address used for communication of 

bearer traffic packets (carrying telephony media such as voice). This is because a NAT 

typically dynamically assigns addresses on an as-needed basis after a call session has been 

established and bearer traffic packets are actually communicated. A need thus exists for an 

improved method and apparatus of providing telephony services to terminals or systems 

i ■ 
behind a firewall and NAT. 



20 



25 



Summary 



adapted 
address 
firewall 



] n general, according to one embodiment, a device capable of being used in 
communications jthrough a firewall and network address translator includes an interface 
to exchange messages with a node on another side of the firewall and network 



translate The exchange of messages is initiated by the device, which is behind the 
and network address translator. The :ex change of messages between the device and 
the node results in creation bf a path through the firewall and network address translator. A 
controller is adapted to repeatedly send keep-alive messages to maintain the path through the 
firewall jand network address translator. 

In general, according to another embodiment, a system for use in communications 
between a first terminal and a second terminal, with the first terminal coupled to a remote 
network address translator, includes an interface adapted to communicate with the remote 



30 network 



address translator. The system further includes a storage module to store network 



address translation information for the first terminal. A controller is adapted to partially 
create tl)e network address translation information during setup of a communications session 
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between the first: and second terminals and to wait for a media packet originated by the first 



termina 



after th 



advanta 



; communications session has been set up to complete the network address 
translation infor nation. 

Some embodiments jof the invention may have one or more of the following 
i ges. By [maintaining a path through a firewall and network address translator, the 

path can be used for control signaling communicated from outside a private network to a 

i 

terminal behind the firewall and network address translator to establish communications 

I ;: 

sessions (e.g., call sessions). Using techniques according to some embodiments, substantial 
modification of the firewall and network address translator can be avoided. As a result, the 
firewall does not! need to be aware of the underlying protocol used for the communications 
session. 

Other features and advantages will become apparent from the following description, 
from the drawings, and from the claims. 



15 Brief Description Of The Drawings j ; 

] ? ig. 1 is k block diagram of an example communications system that incorporates an 
embodiment of tpe invention. 

Fig. 2 is a block diagram of components of an application server and a media portal, 
in accordance with an embodiment. 
20 Fig. 3 illustrates mapping of source and destination addresses and ports in a media 

packet by the mejdia portal. 

Fig. 4 is a message flow diagram of a registration procedure by a device behind a 
firewall tand network address and port translation (NAPT) module, in accordance with an 
embodiment. 

25 Fig. 5 is a message flow diagram of a call setup procedure between devices behind 

respective firewall and NAPT modules, in accordance with an embodiment. 

Fig. 6 is si message flow diagram of a process of updating NAPT tables in respective 
media portals in response to. communication of media packets by the devices of Fig. 5. 



30 Detailec 



Description 



In the following description, numerous details are set forth to provide an 
understanding of the present invention. However, it will be understood by those skilled in the 
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art that jhe present invention may be practiced without these details and that numerous 
variations or modifications from the described embodiments may be possible. 

: leferring to Fig. 1, a communications system 10 includes a public network (e.g., the 
Internet!) 14, an enterprise 16 (e.g., a company, a government agency, a university, or other 
5 organization of multiple users), a service provider 12, and a public switched telephone 
network (PSTN) 20. The arrangement of Fig. 1 is shown for purposes of illustration and 
example, as other embodiments can have other arrangements. 

The service provider 12 includes a private network 50 coupled to various internal 
nodes, and the enterprise 16 includes a private network 26 coupled to various internal nodes 

i 1 s 

10 and terminals. T|he service provider 12 enabtes access by subscribers of various resources in 
the communications system 1 10, including the public network 14 and the PSTN 20. Thus, a 
user station coupled to the public network 14, such as one of user stations 22 or one of user 

|i : ! 

stations 24 in the; enterprise 16, can perform' various forms of communications through the 

service providerl2. Examples of possible communications include real-time, interactive 

i 

15 communications (e.g., voice, video conferencing, interactive electronic gaming, file transfer, 
whiteboarding. and so forth). Interactive electronic gaming refers to a session in which data 
associated with an electronic game (e.g., chess) is exchanged between two or more players 
over a network. Whiteboarding refers to a session in which notes can be written by 
participants of the session over a network to a virtual whiteboard. 

20 The user stations 24, which are connected to the enterprise private network 26, 

commuiicate with the public network 14 through a border system 28. In one example, the 
border system 28 includes a firewall and network address and port translation (NAPT) 
capabili ies, whijfh are provided by a firewall device and an NAPT device. The firewall 
device aid NAPT device can be implemented as separate components on separate platforms, 

25 or they < an be integrated onjthe same platform. In the ensuing discussion, a firewall device 
and NAPT devicje are referred to collectively as a "firewall and NAPT module." However, 
althougl referred to in the singular, the firewall and NAPT module can be made up of plural 
modules (implemented as software, hardware, or a combination thereof) in the border system 
28 or in multiple systems. Also, although the discussion refers to features of the firewall and 

30 NAPT module, it should be understood that certain features are provided by the firewall 

portion While other features are provided by the NAPT module. As will be described further 
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below, various issues are associated with provision of telephony services by the service 
provider 12 to devices behind the firewall and NAPT module. 

The userstations 22 and 24 shown in Fig. 1 can be network telephones (which are 
telephones including a network interface to enable communication with a packet-based 
network), computers fitted with voice processing capabilities (referred to as "softphones"), or 
other tenninals capable of participating in real-time, interactive communications sessions. 
One exEmple of a network telephone is the i2004 telephone from Nortel Networks. 
Exampl 5S of other user stations that can be endpoints of communications sessions include 
mobile stations 30 coupled by wireless links to a radio access network (RAN) 32, which is in 
turn connected to the PSTN 20. Also, a wired telephony device 34 can be coupled to the 
PSTN2jO. 

The service provider 12 includes various components that are visible on the public 
network! 14, including a web server 38, a network telephone manager 40, application servers 
42 and 43, and niedia portals 44 and 45. The service provider 12 includes internal nodes that 
are not visible to.;the public network 14, including a gateway 36 to the PSTN 20, a database 
server 4 3, an announcement server 49, and other nodes (not shown). The gateway 36 
translates betweeh call control signaling and media according to a first format (e.g., packet- 
based format) used on the public network 14 and another format (e.g., circuit-switched 
format) ised on lie PSTN 20. The database server 48 stores information of registered 
devices, includir jg information relating to which domain the devices are in, and other 

! ■ i 

informaion. j : j 

r Tie web Server 38 presents web pages that can be browsed by users on the public 
networkj 14. The network telephone manager 40 is used for managing network telephones. 
The network telephone manager 40 generates and receives call control signaling on behalf of 

the netw'ork telephones. Once a call is established, media is communicated directly between 

j 

two endpoints (e.g., two network telephones). In other embodiments, the network telephones 
may be capable of exchanging and processing call control signaling without the assistance of 
the network telephone manager 40. 

The application server 42 or 43 communicates call control signaling with stations or 
nodes on the public network 14 or on the private network 50 for establishing a call. Once the 
call is established, media and/or bearer traffic is communicated through the media portal 44 
or 45 be ween enkpoints. In one embodiment, the media packets can contain Real-Time 
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Protocol (RTP) lata that are carried within a User Datagram Protocol (UDP)/Intemet 

Protocol (IP) packet. j 

! ! ' : 

. n one example, call control signaling for establishing a call session is according to a 

Session Initiation Protocol (SIP). SIP is part of the multimedia data and control architecture 

from the IETF, and one version of SEP is described in Request for Comments (RFC) 2543, 

entitled "SIP: Session Initiation Protocol," dated 1 999. SIP can be used to initiate call 

sessions as well as to invite members to a session that may have been advertised by some 

other mechanisni, such as electronic mail, web pages, and so forth. RTP, which defines a 

protocol for transporting real-time data, is described in RFC 1889 entitled "RTP: A 

Transport Protocol for Real-Time Applications," dated January 1996. UDP defines a 

transport layer that is described in RFC 768, entitled "User Datagram Protocol," dated 

1980. One version of IP is described in RFC 791, entitled "Internet Protocol," dated 



August 



September 1981 



Protoco 



Version 6 (IPv6) Specification," dated December 1998. Other standards can also be 



while another version of IP is described in RFC 2460, entitled "Internet 



15 employed to provide call control signaling, such as the H.323 Recommendation from the 

I I ' ! 

Internat onal Telecommunication Union (ITU). 

As used here, a "call session" refers generally to a real-time, interactive 

communications session that involves the exchange of real-time data between multiple 



parties. 



An interactive communications session refers to a session in which two or more 



20 parties £re involved in an exchange of data. A real-time, interactive communication session 
refers to an exchange of data, such as audio and/or video data, on a substantially real-time 
basis between two endpoints. A session is substantially real-time if interaction is occurring 
between! two endpoints with communication from one endpoint followed relatively quickly 
by a response or. another communication from the other endpoint. A "call request" is a 

25 message for establishing a call session. A "media packet" or "media data unit" refers to a 
packet dr data uitit carrying bearer traffic (e.g., voice data, video data, interactive electronic 
gaming pata, file jtransfer data, whiteboarding data, etc.) in a call session. 

In accordance with Some embodiments of the invention, telephony services are 

r i i ■ 

provided by the service provider 12 to devicies on the enterprise private network 26 without 
30 substantial modification of the firewall and NAPT module (refeired to as the "enterprise 
firewall Jand NAPT module") in the border system 28. An issue associated with 
providing telephony services to a device behind an enterprise firewall and NAPT module is 
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that the firewall and NAPT module prevents unsolicited access by an external device. Unless 
a path thjrough the enterprise firewall and NAPT module is opened, the firewall and NAPT 
module hides the identity (address and port) of the device behind the firewall and NAPT 
module. Thus, any incoming calls to such a device would be unable to reach the device. To 
address vhis issue in accordance with one embodiment of the invention, a path or connection 
is create 1 and maintained between a device behind the firewall and NAPT module and the 
application server 42 or 43 (which includes a SEP proxy or other like device). Maintenance 
of the p£ th is accomplished by using a "keep-alive" signaling mechanism that issues periodic 
messages between the device and application server 42 or 43, which allows the firewall and 
NAPT module tq maintain allocation of resources (e.g., network address and port) for the call 
session. 

The use of keep-alivfe messages to maintain the path is needed in some embodiments 
for two reasons. One is that UDP provides for connectionless communications between two 
endpoinis. Another is that once a message is sent by a device behind an enterprise firewall 
and NAPT module is sent, the path through the enterprise firewall and NAPT module through 
which responses, can be sent to the device is maintained open for only some preset amount of 
time. Ajfter the preset amount of time, the path is closed. 

Another issue associated with creating call sessions with a device behind an enterprise 

firewall and NAPT module is that the external address and port of the device behind the 

II! 

enterprise firewall and NAPT module allocated for media communications (communications 



module tioes not 
commuiications 



of media packets 



carrying bearer traffic such as voice) is unknown until the device actually 



i 1 i 

starts sehding media packets. This is due to the fact that the enterprise firewall and NAPT 



allocate an 



external address and port to the device for media 
untilmedia communications' actually start. Note that during call session 
setup, the enterprise firewall and NAPT module allocates an external address and port to the 
device for communication of call control signaling-however, the control address and port is 
different from the media address and port for communication of media packets. 

One of the tasks performed by the media portal 44 or 45 is network address and port 
translatibn (NAPT) of media packets exchanged during a call session. Note that an NAPT 
module in the media portal 44 or 45 is separate and distinct from the enterprise firewall and 
NAPT module. Whereas the enterprise firewall and NAPT module is provided to protect 
devices on the enterprise private network 26, the NAPT module in the media portal 44 or 45 
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is provided to hide identities of devices on the service provider private network 50 and to 
shield identities of endpoints that communicate media packets through the media portal 44 or 
45 during a call |ession. The NAPT module in the media portal 44 or 45 translates hoth the 
source aid destination addresses (e.g., IP addresses) and ports (e.g., UDP ports) of each 



received packet. 



This is a departure from standard network address and port translators, 



which typically translate only one of the source and destination addresses for a given 
direction of the media packet. 

! To perform NAPT, the media portal 44 or 45 maintains an NAPT table that contains 
information for mapping addresses and ports in media packets. The media portal 44 or 45 is 
able to partially create NAPT mappings during a call establishment flow, but the media portal 
44 or 45j waits until the first media packet arrives from device(s) behind respective firewall 
and NAPT module(s) before the NAPT mappings can be completed. 

Although reference is made to NAPT modules that translate both network addresses 
and port s, other embodiments may involve translation modules that translate only the 

address or only the port. Calls handled through the service provider 12 can involve 
s that ar/e both located outside the private network 50, such as user stations 22 and/or 
Alternatively, a call can involve an endpoint outside the service provider 



network 
endpoin 
user stations 24. 



private network :>0 and a node on the service provider private network 50, such as the 

! ! 

gateway 36 or thp announcement server 49. Also, although only one enterprise 16 is 
illustrated in Fig: 1 , other arrangements can have plural enterprises with their respective 
enterprise private networks and firewall and NAPT modules. 

The various arrangements described herein are provided as examples only, as other 
embodiments may utilize other arrangements. 

Referring to Fig. 2, components of the application server 42 or 43 and the media 
portal 44 or 45 are illustrated. The application server 42 or 43 includes control logic 100 and 
a call processing 'module 102. The call processing module 102 receives call control signaling 
from the public network 14 and the private network 50. The call processing module 102 



30 



includes 
above tt 

embodiment, the! 



a network interface 104 to the public network 14, one or more protocol layers 106 
e netwo 'k interface: 1 04, and a SIP stack 108 for processing SIP messages. In one 
protocol layers 106 include a UDP transport layer and an IP network layer. 
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Tjne call processing module 102 also includes a second network interface 110 coupled 
to the private network 50, and one or more protocol layers 112 above the network interface 
110. ! 

i 

llie control logic 100 of the application server 42 or 43 communicates with host logic 
114 in the mediatorial 44. The control logic 100 and host logic 114, which can be 
implemented in software or a combination of software and hardware, employ a predefined 
messaging scheme to exchange messages with each other. In one example, the messaging 
scheme is according to an enhanced version of the Media Gateway Control Protocol 
(MGCP], as described in RFC 2705, entitled "Media Gateway Control Protocol (MGCP), 

Version 1.0," dat!ed October 1999. Enhancements to the MGCP messages are added to 

! j 

support ransportiof certain types of data between the media portal 44 or 45 and the 

! j \ ! 

application server 42 or 43. 'The enhancements include the introduction of a new format of a 

parameter Endpc jntld used io identify endpoints and a parameter (referred to as 

X+NAPTAddresteType) to specify the type of'network mapping. Such enhancements are 

explained below. 

The media portal 44 or 45 also includes a media packet engine 1 1 6. In one 
embodiment, theimedia packet engine 1 16 can be implemented on multiple circuit boards or 
blades (each with' two interfaces to the public and private networks 14 and 50) to enhance 
concurrent communication of messages. The media packet engine 116 includes a first 



20 network 



protocol 



interface 1 1 8 coupled to the public network 14, and one or more protocol layers 120 
above the network interface 118. Similarly, a second network interface 122 is coupled to the 
private r etwork 50, and one or more protocol layers 124 are provided above the network 
interface 122. Aa RTP/RTCP module 126 is also part of the media packet engine 116. RTP, 
which provides a mechanism for transporting real-time data across a packet-based network, is 
an application sublayer that typically runs on top of the UDP layer (which is part of the 



layers 1 



20 or 124). 



Specified along JITP is the Real-Time Control Protocol (RTCP), 
which provides a mechanism for sharing various session data between endpoints. In 
accordance with one embodiment, voice and other forms of real-time data are carried in RTP 
packets communicated across the public network 14 and the private network 50. 

Also included in the media packet engine 1 1 6 is an NAPT module 127 and an NAPT 
table 128 that contains plural entries 130. Each entry of the NAPT table 128 contains 
mapping information for source and destination addresses and ports of media packets 
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received from the. networks 14 and 50. For a given call session involving a first device and a 
second device, each NAPT table entry includes a first address and port of the first device, a 
second Jddress and port of the second device, a first alias address and port mapped to the first 
device address and port, and a second alias address and port mapped to the second device 



address and port 



The contents of each NAPT table entry are discussed further below. The 



NAPT fable entrj is dynamipally updated as ;a call session is being established. Once the call 
session is terminated, the allocated resources in the NAPT table entry are deleted and made 
available to othei jcall sessions. ; 

Ihe NAPT table 128 is stored in a storage module 132. The NAPT module 127 uses 
1 0 information in the NAPT table 128 to perform network address and port translations. 

Referring to Fig. 3, the network address and port translation performed in the media 
portal 4' or 45 according to an embodiment is illustrated. A received IP packet 200 contains 
a payload section' 209 (which includes the RTP packet), an IP header 201, and a UDP header 

205. Thfe IP header 201 contains a source network address 202 and a destination network 
15 address 204, in addition to other information. The UDP header 205 contains a source port 

206, a destination port 208, and other information. The IP packet 200 is applied (at 210) 
through NAPT mapping based on the NAPT table 128. The output packet 220, after the 
NAPT mapping, includes the same payload 209, but the source and destination addresses and 
source and destination ports have been translated. The source network addresses 222 has 

20 been 'translated from IP address IPi to P address IP] 1 , the destination address 224 has been 

i 

translated from I ?J to IP2, the source port 226 { has been translated from port P] to port Pi 1 , 
and the destination port 228 has been translated from port P2 1 to port P 2 . 

Thus, from the perspective of each endpoint, the media portal 44 or 45 is the node that 
each enc point is communicating with. In effect, the media portal 44 or 45 masquerades as 

25 the endpbint in a call session that each of the two "real" endpoints is communicating with. 
As notecj above, the media portal 44 or 45 resides in the media path of a call session for 
communicating media packets containing bearer traffic. Note that if one of the endpoints is 
behind an enterprise firewall and NAPT module, then the NAPT mapping in the media portal 
44 or 45|is not completed until the endpoint behind the enterprise firewall and NAPT module 

30 sends its; first media packet. 

In the control path, the application server 42 or 43 serves as the SIP proxy for one or 
morejOf the user jstations 22 or 24 and other devices (e.g., the gateway 36) that are capable of 
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participating in call sessions. Thus, as each user station 22 or 24 or other device is started, 
the user station [22 or 24 or other device performs SIP registration with the application server 
42 or 4 J. 

Fig. 4 sliows an example registration procedure that involves a first pair of application 
server £nd media portal (421 and 44), a second pair of application server and media portal (43 
and 451 a first firewall and NAPT module FNA, a second firewall and NAPT module FNB, 
and devices A and B. Device A resides behind the firewall and NAPT module FNA (such as 
in a first border system, e.g., 28 in Fig. 1), while device B resides behind the second firewall 
and NAPT module FNB (e.g., in another border system). As illustrated, device A sends (at 
302) a SIP REGISTER message to the first application server 42, with the SIP REGISTER 
containing the following according to one example: 



IP Header: 
arc =10.1.1.1 
15 dst = 147.3.3.3 

UDP Header: 
src port = 5060 
dst port = 5060 
Payload: 

20 SIP REGISTER 

From: A@xxx.com 

["NAPT Active" flag*] 
The SIP REGISTER packet includes an IP header containing source and destination 

25 IP addresses, a UDP header containing source and destination UDP ports, and a payload. The 
source network address and port (e.g., 1 0.1.1.1 :5060), which is a private address that has 
meaning only on the enterprise private network 26, identifies device A, while the destination 
network; address and port (e.g., 147.3.3.3:5060), which is a public address, identifies the first 
application server 42. The payload of the SIP REGISTER message indicates that the 

30 registrat on is being attempted from device A (having identifier A@xxx.com). In addition, 
the payload has an NAPT Active flag, which indicates that the message is from a device that 
is subject to enterprise NAPT (which allocates a public address for device A). In one 
embodinent, the NAPT Active flag is inserted into the SIP REGISTER message payload by 
the device A. This flag is used to indicate special handling at the application server. 
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The SIP REGISTER message is routed through the firewall and NAPT module FNA, 
which cijeates a mapping (at 304) between the source address and port Ai nte niai (of the device 
A) and dn available external address and port A pu biic (allocated by the firewall and NAPT 
module FNA). This mapping is maintained by the firewall and NAPT module FNA to 
provide a path for responses to flow back to device A. Conventionally, the mapping is 
removed after a configured time interval passes. However, as explained below, the mapping 
is maintained by !a keep-alive signaling mechanism to allow a signaling path between device 
A and the application server 42 through the firewall and NAPT module FNA. 

ITie fireball and NAPT module FNA forwards (at 306) the SIP REGISTER message 
to the fiist application server 42. The SIP REGISTER message remains the same, except the 
source network address and jport Asternal in the DP and UDP headers in the REGISTER 
message has bee i replaced ivith A pu bii C . Upori receipt of the SIP REGISTER message, the 

l> i 

first application server 42 determines that the NAPT Active flag has been set and creates (at 
308) an association between A@xxx.com and the From: address (A pu bii C ) in the packet. This 

i ; 

is contrasted to the standard process of mapping A@xxx.com to the SIP REGISTER Contact: 
Address! If needed, the application server 42 creates or updates a profile associated with the 
registering device in the database server 48. 

The first application server 42 then responds (at 310) with a SIP 200 OK message. 
This message is sent to the enterprise NAPT address (Ap Ub ii C ), not the "real" address (A^mai) 
of device A, sincje the "real" address is a private address and cannot be properly routed on the 



public n stwork. 
example: 



The SIP 200 OK message has the following content according to one 



IP Header: 
src = ]147.3.3.3 
dst = 147.2.2.2 
UDP [Header: 
src port = 5060 
dst port = 6000 
Payload: 
SIP 200 OK 



the SIP 200 OK message routes to the enterprise firewall and NAPT module FNA for 
xxx.com, where the public destination address (A pU biic or 47.2.2.2:6000) is mapped to the 
internal address and port (A in temai) of the originating tenninal. The P/UDP headersof the 
packet cpntaining the SIP 200 OK message are modified, and the modified packet is sent by 
35 the enterprise firewall and NAPT module FNA (at 312) to device A. The modified SIP 200 
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OK message is the same as the original SIP 200 OK message except the destination network 

address bid port in the IP and UDP headers of the OK message has been changed from A pu b]j C 

to Ainterrai. The device A receives the SIP 200 OK message as confirmation that the 

; j 
registrat ion was successful. 

5 At this priint, a two-way signaling path exists between device A and the application 

! i 

server 42 throug jt the firewall and NAPT module FNA. The firewall and NAPT module 
FNA includes a timer that vvhen expired causes the signaling path between the device A and 
application server 42 to be closed (which results from the NAPT mapping in the application 
server 42 being removed). 
10 '"o maintain the signaling path active, device A periodically transmits (at 3 14) a 

"keep-al ive" message through the enterprise firewall and NAPT module FNA to maintain the 
mapping of the SjlP signaling addresses for the duration of the registration. In one example, 
the keep-alive message is a SIP PING message. In other embodiments, other types of keep- 

i 

alive messages can be used. The SIP PING message, which contains the source address and 
15 port of c evice Ajiand the destination address and port of the application server 42, causes the 
timer in the firewall and NAPT module FNA to reset and start a new count-down, thereby 
enabling i the allocation of mapping resources and thus the signaling path through the firewall 
and NA 3 T modi ie FNA. In another embodiment, the keep- alive messages are initiated by a 
network server ( ?.g., the application server 42 or some other network node) rather than device 
20 A. ' 

The timing of the keep-alive messages is controlled by a timer 350 in device A. The 
timer 350 can be configured to count a predetermined time period after which the keep-alive 
message is transmitted. Enterprise device A also includes a control module 354 
(implemented in software and/or hardware) that provides control tasks (e.g., exchanging call 
25 control signaling and communicating media traffic) for the enterprise device A. The 

enterprise device! A also includes an interface 358 that enables communications over data 
networks. 

Device Bj, which is in a separate enterprise private network associated with firewall 

and NA 5 T modi Ie FNB, performs a similar registration process (at 316) with the second 

i j 

30 application server 43. A mapping is created>(at 31 8) by the enterprise firewall and NAPT 
module FNB between the internal network address and port (Bintemai) and an externa] or 
public n stwork address and port (B pU biic). The second application server 43 also creates (at 
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320) an kssociati j>n between| B@yyy.com andjthe external network address and port B pu biic 
that the message came from: To maintain the SIP signaling path open, enterprise terminal B 
also periodically sends (at 322) keep-alive messages. 

Enterprise B includes a timer 352, control module 356, and an interface 360 that are 
similar to respective components in enterprise A. In the above example, the enterprise 
devices A and B contain timers to enable them to send keep-alive messages. However, in an 
alternative embodiment, the application server 42 or 43 can include the timer and logic to 
send keep-alive messages to the enteiprise devices A and B. 

Thus, a SIP registration process is provided that enables a signaling path to be 
maintained between an enterprise device and a SIP proxy (the application server 42 or 43) 
through an enterprise firewall and NAPT module (FNA or FNB) for the duration of a given 
SIP registration, jvithout requiring that the enterprise firewall and NAPT module be aware of 
SIP. Tk s is refe jred to as a ^"transparent firewall" functionality. However, although a 
constant signaling is established for the enterprise device in the registration process, the same 
is not tn e of the media pathj The media pathlactually changes on a per-session basis. This is 
due to the fact that the enterprise firewall and NAPT module dynamically assigns mappings 

as requiijed from its currently available pool of resources. An implication of this is that the 

i 

enterprise firewall and NAPT module only sets up the mapping upon receipt of a media 
packet, which happens to occur after call setup has been completed and media packets are 
actually communicated. 

The above example assumes that the enterprise devices A and B are SIP-enabled (that 
is, they are capable of exchanging SIP messages). However, in some cases, the enterprise 
device A or B may not be SIP-enabled. An example of such a device is the i2004 network 
telephone, whicWcooperates with a network telephone manager (e.g., the network telephone 
manager 40 in Fig. 1). In this alternative arrangement, the enterprise device A or B sends a 
"ResumaConnec ion" message (instead of a SIP REGISTER message) to the network 

; I j 

telephone manager 40 through the firewall anji NAPT module. A signaling path through the 
firewall and NAPT module is established between the enterprise device and network 
telephone manager 40. The SIP registration process for the enterprise device A or B can 
occur bejtween the network telephone manager 40 and application server 42 or 43 over the 
service provider private network 50. 



4 
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lilaintenance of the signaling path in this alternative embodiment between the 
enterprise device and the network telephone manager 40 is similarly accomplished by using a 
timer in |the network telephone manager 40, which periodically sends a message (based on the 
timer) to! the enterprise device A or B. The enterprise device A or B acknowledges the 
5 message, thereby keeping the signaling path open. Again, the enterprise firewall and NAPT 



module need not 
manage: 40 and 1 



be aware of the telephony protocol used between the network telephone 
he enterprise device A or B. 
deferring to Fig. 5, a call setup process is illustrated, in which NAPT mappings are 
established for enterprise devices A and B that reside behind respective firewall and NAPT 
10 modules FNA and FNB. In the example of Fig. 5, enterprise device A is the one that initiates 

the call session. Enterprise device A does this by sending (at 402) a call request (e.g., a SIP 

i 

INVITEj message) to the first application server 42 through the enterprise firewall and NAPT 

module FNA. The firewall and NAPT module FNA locates the associated mapping between 

I 

the internal source address and port (Asternal) and the assigned external address and port 
15 (Apubiic).: This mapping was established when enterprise device A initially registered for 

service with the first application server 42 (see Fig. 4), which has been maintained through 
the use of periodic keep-alive messages. 

i^n example SIP INVITE message is shown below: 
IP Header: 

20 src= 10.1.1.1 

dst= 147.3.3.3 
UDP Header: 
src port = 5060 
dstpcjrt = 5060 
25 ! Payload: ; 

SIP INVITE 
From: A@xxx.com 
To: B@yyy.com 
SDP: RTP/RTCP 10.1.1.1:1000 

s 

30 The source address and port Asternal (10.1 .1 .1 :5060) specifies enterprise device A, 

while the destination network address and port (147.3.3.3:5060) specifies an address and port 
of the first application server 42. The payload section of the IP packet contains a SIP 
INVITE message, which contains a From: address, e.g., A@xxx.com (identifying enterprise 
device A), and a To: address, e.g., B@yyy.com (identifying enterprise device B). The SDP 

35 portion of the SIP INVITE message specifies the media network address and port 

(AmediajJ temai, whjich in the ex ample is 1 0. 1 . 1 . 1 : 1 000) where device A desires to receive media 
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packets. 



Amediajntemai is a private address and port used by the enterprise device A for 



communicating media packets. Note that A me <iia_internai f° r media packet communications is 
differen from A ntemai for control signaling communications with the enterprise device A. 
The firewall and NAPT module FNA substitutes 

Apnvate 

(the source address and port 
in the H and UDP headers of the packet containing the INVITE message) with A pu bii C , and 
forwards the modified packet containing the SEP INVITE message (at 404) to the first 
application server 42. 

Upon receiving the SIP INVITE message, the first application server 42 locates the 

i 

application server for the yyy.com domain (of enterprise device B), and engages the first 
media portal 44 tb prepare NAPT mappings for the call session that is to be established. The 
application server 42 sends (at 406) a message to the media portal 44 to create the NAPT 

i 

mapping information (in the form of an entry in the mapping table 128). In one embodiment, 
the requfest includes an MGCP CreateConnection message, with one example provided 



below: 



CRCX 1234 A:0000@0.0.0.0 MGCP 0.1 
C: 987651 
M: recvonly 

X+NAPTAddressType: ON:INT, TN:EXT 

i 

MGCPVerb = CRCX (CreateConnection) 
Transactionld = 1234 
Endpointld = A:0000@0.0.0.0 
MGCPVersion = 0.1 
Callld = 987651 

ConnectionMode = recvonly (receive only) 
NAPTAddressType = ON:INT, TN:EXT 



35 



One pertinent field of the CreateConnection message is the parameter Endpointld, 
which is 1 equated to A:0000@0. 0.0.0 (a dummy address), where A represents audio. For 



30 video or 



other media, other indicators are used. The dummy address is used as an indicator 
that the uddress should be filled in later. The Endpointld parameter, which is a parameter 
whose format ha! been altered from the standard MGCP-defined Endpointld as an 
enhancement, identifies the address and port that the media portal 44 is to allocate resources 
for. The example provided above (and elsewhere in this description) is a relatively simple 
implementation of Endpointld. Other fuller implementations include providing a larger part 
of the miedia description that is in the SDP portion of the INVITE or other SEP message). 
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terminat: 
(referred 

X+NAPTAddres 



Also, a Callld parameter is supplied in the MGCP CreateConnection message. The Callld 
parameter is used as a key to point to an entry in the NAPT mapping table 128. 

Another parameter in the MGCP CreateConnection message is a parameter 
X+NAPTAddressType to identify the different types (internal or external) of endpoints. The 
X+NAPTAddressType parameter is also added to the MGCP CreateConnection request as an 
enhancement. From the perspective of the media portal 44 in the example above, the address 
and port of the media portal 44 interfacing the originating endpoint, which is the enterprise 
device A (through the enterprise firewall and NAPT module FNA), is a public address and 
port (referred to as B m edia")- The address and port of the media portal 44 interfacing the 
10 terminating endpoint, whichiis the second media portal 45, is a private address and port 

i 

to as Arledia') on the service provider private network 50. Thus, the 

Type parameter is used to assign the appropriate public and private NAPT 
addressejs and ports in the media portal 44. 1 

The first application server 42 uses the X+NAPTAddressType parameter to inform 
15 the first media portal 44 to allocate a public NAPT address and port (B me dia" or TN) to 

interfacej the originating endpoint (enterprise device A through the enterprise firewall and 

NAPT module FNA), and to allocate a private NAPT address and port (Amedia' or ON) to 

i ; 

interface! the terminating endpoint (media portal 45). TN is the address and port at the media 
portal 44 or 45 that represents the terminating endpoint to the originating endpoint, while ON 

20 is the address and port at the media portal 44 or 45 that represents the originating endpoint to 
the terminating endpoint. In this example, media packets are exchanged between Acedia (at 
the enterprise firewall and NAPT module FNA) and Bmedia" ( at * e media portal 44); and 
media packets ar 5 exchanged between Bmedia' (at the second media portal 45) and Amedia' (at 
the first media pojrtal 44). When a media packet is received by the media portal 44, Amedia is 

25 mapped to A me dia ] while Bme&ia' is mapped to Bmedia' 

In response to the MGCP CreateConnection request above, the media portal 44 
reserves NAPT resources (at 408) for communications of media packets in the call session. 
Howevei, at this point, the first media portal 44 is unable to build a complete mapping of the 
address and port space. The reason for this is that the address and port supplied in the SDP of 

30 the SIP INVITE is enterprise device A's private address (Amedia jmemai), which is not 

accessible from the outside world. Therefore, a dummy address and port is used to indicate 
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this spebial case (e.g., 0.0.0.0:0000) using the Endpointld parameter in the MGCP 
CreateConnection message. 

The first-media portal 44 reserves two available NAPT network addresses and ports: 
the originating } (APT address and port (Amedia') and the terminating NAPT address and port 

' i 

(Bmcdia' ). However, the originating endpoint network address and port (A me dia) is not known 

at this point, noi jis the terminating endpoint network address and port (B me dia'). T^ e mapping 

! i : 

table entry at this pomt is shown below: j 



Callld 


OrigEndpoint 

(A me dia) 


OrigNAPTAddr 

(A m cdia ) 


TemiNAPTAddr 

(Bmcdia") 


TerrriEndpoint 

(BmediaO 


987651 


A:0000@0.0.0.0 


A:4000@l 92.1 68.4.4 


A:4000@147.4.4.4 


??? 



pie mapping table entry is pointed to by the Callld parameter, which is used as a key. 

Next, the'first media portal 44 returns (at 410) the originating NAPT address and port 
(Amedia') to the first application server 42. The first application server 42 also responds (at 
412) to enterprise device A with a SIP 100 TRYING. Note that the TRYING message is 
likely to have been communicated earlier (for example, right after the application server 42 
received the SIP INVITE message at 404). 

i Next, thejifirst application server 42 performs a substitution of A mc dia>temai with 

Amedia' i i the SDP portion of the SIP INVITE message. The modified SIP INVITE message 

! \ 

is sent (at 414) to the second application server 43. 

When the modified SIP INVITE message arrives at the second application server 43, 
the second application server 43 locates B@yyy.com and engages the second media portal 45 
to reserve NAPT resources. This is accomplished by sending (at 416) an MGCP 
CreateCjonnection message to the second media portal 45. From the perspective of the 
second media portal 45, the originating endpoint (Amedia') is the first media portal 44, which 
is on the service provider private network 50. The terminating endpoint (Bmediajntemai) is 
behind a firewall and NAPT module FNB served by the second application server 43. The 
firewall ;and NAPT module FNB dynamically maps Bmediajntcmai to an external network 
address and port B 

media* 

i 

The netwjork connection between the second media portal 45 and Amedia' is a private 



network 



connection (on private network 50), while the network connection between the 



30 media portal 45 and B media is a public network connection. The second application server 43 
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uses thd X+NA£TAddressType parameter in the CreateConnection message to inform the 
media portal 45 to Allocate respective 1 NAPT (external and internal) addresses and 



second 



li 



ports to each endpoint. In this example, the originating endpoint (Amedia') is an internal 
network address, so the NAPT address B me dia' or TN of the second media portal 45 that 
communicates with A m edia 5 is assigned as an internal address. The terminating endpoint 
B m edia is an external public network address, so the NAPT address A m edia" or ON of the 
second media portal 45 that communicates with B me di 8 is assigned as an external address. 

The MGCP CreateConnection message sent at 416 according to one example is as 
follows: 

CRCX 1234 A:4000@192.168.4.4 MGCP 0.1 
C: 987651 
M: recvonly 

X+NAPTAddressType: ON:EXT, TN:INT 

MGCPVerb = CRCX (CreateConnection 

Transaction^ = 1234 

Endpointld = A:4000@l 92. 168.4.4 

MGGPVersion = 0.1 

Callld = 987651 

ConnectionMode = recvonly (receive only) 
NAPTAddressType = ON:EXT, TN:INT 

The second media portal 45 reserves (at 418) two available addresses and ports: 

originatjng NAPT network address and port (Amcdia") and terminating NAPT address and 

port (Bmedia')- The created partial table entry is as follows: 



Callld 


! OrigEndpoint 

j (Amedia ) 


OrigNAPTAddr 


TemiNAPTAddr 

(Bmedia') 


TermEndpoint 

(Bmedia) 


987651 


| A:4000@192.1 68.4.4 


A:2020@161.6.6.6 


A:3300@192.1 68.6.6 


??? 



: the table; above specifies a mapping between Amedia' and Amedia" > and a mapping 
betweer B mC dia' and B mC dia. The second media portal 45 returns (at 420) the originating 
NAPT i ddress and port (Amedia") to the second application server 43. The second application 
30 server 43 then responds (at $22) to the first application server 42 with a SIP 1 00 TRYING 
message;. 

the second application server 43 modifies the SP INVITE message and forwards it 
(at 424)!to enterprise device B through the firewall and NAPT module FNB. The second 



4 
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applicatibn server 43 modifies the SIP INVITE message by changing the SDP portion to 

SUbstitUtjS Amcdia' with Amedia' ' . 

The firewall and NAPT module FNB performs another address and port translation, in 
which the destination address and port B pub iic in the IP and UDP headers of the SIP INVITE 
5 message is changed to Bintemai. The modified packet containing the SIP INVITE message is 

then forwarded (at 426) to enterprise device B. 

i 

Enterprise device B then signals the originating terminal with a SIP 180 RINGING 
message This is propagated (at 428) all the way back to enterprise device A through various 
intermediaries. When enterprise device B answers, it sends a SIP 200 OK message (at 430) 

r I 

i , : 
10 to the se :ond application server 43 . 

J H I 

The SIP 200 OK message according to one example includes the following: 

IP Header: 
src = 10.5.5.5 
dst = 161.4.4.4 
15 UDP Header: 

src port = 5060 
dst port = 5060 
Payload: 
SIP 200 OK 

20 From: B@yyy.com 

To: A@xxx.com 
SDP: RTP/RTCP 10.5.5.5:2000 

The SDP portion of the SIP 200 OK message contains the source network address and 

port (Bmsdia internal) of enterprise device B for media communications where device B desires 

25 to receive media packets. However, because this address and port is private, it cannot be 
used by external devices for (communication with the enterprise device B. 

Upon receiving the ^IP 200 OK message, the firewall and NAPT module FNB locates 
the associated mapping between the source address and port Bj nte mai for device B and the 
assigned! external address and port B pU biic- This mapping was established as part of the 

30 registration procedure described above, and maintained through the use of the keep-alive 

messageL The firewall and NAPT module FNB substitutes the source address and port in the 
IP and UPDP headers of the SP 200 OK message (replacing B ime mai with B pu bii C ), and forwards 
(at 432) the message to the second application server 43. When the second application server 
43 receives the SIP 200 OK message, it sends a ModifyConnection request (at 434) to the 

35 second media portal 45. 
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Since enterprise device B is configured behind the enterprise firewall and NAPT 
module FNB, ttie actual media address and port for enterprise device B will not be known 
until th ? enterpmse device B transmits its first media packet through the enterprise firewall 

and NAPT module FNB. Thus, the address and port B me dia internal in the SDP portion of the 

\ ] ! 

SIP 200 OK me'ssage is discarded, and a "dummy" address (e.g., 0.0.0.0:0000) is used. The 

MGCP ModifyConnection request in one example is shown below: 

MDCX 1237 A:0000@0.0.0.0 MGCP 0.1 
C: 987651 
M: sendrecv 

MGCPVerb = MDCX (ModifyConnection) 
Transaction^ = 1237 
Endpointld = A:0000@0.0.0.0 
MGCPVersion = 0.1 
Callld = 987651 

ConnectionMode = sendrecv (send and receive) 
Using thje Callld parameter as a key, a mapping table entry is identified (at 436), and 
the TenpEndpoint parameter is filled with 0000@0.0.0.0. At this point, the second media 

portal 45 is not Jible to perform the NAPT function yet since it does not have the complete 

i 

mappin i information. \ 

The seccjid media pjortal 45 then returns (at 438) the terminating NAPT address and 
port (B n edia') in an MGCP response to the second application server 43. The second 
application server 43 substitutes (in the SDP portion of the SIP 200 OK message) address 
Bmcdiajnicmai with B me dia', and forwards the SIP 200 OK message (at 440) to the first 
application server 42. 

In response to the SIP 200 OK message, the first application server 42 sends a 
ModifyConnection request (at 442) to the first media portal 44 to allocate the necessary 
NAPT address and port resources. The contents of the MGCP ModifyConnection request is 
as follows: 

MDCX 1237 A:3300@192.168.6.6 MGCP 0.1 
C: 987651 
M: sendrecv 
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MGCPVerb = MDCX (ModifyConnection) 

Transaction^ = 1237 

Endpointld = A:3300@192.168.6.6 

MGCPVersion = 0.1 

CalHd = 987651 

ConnectionMode = sendrecv (send and receive) 
The first media portal 44 uses the Callld parameter as a key to find the mapping 
resources and fills (at 444) in the TermEndpoint field with address B me dia'. The updated 
mapping table entry is as follows: 



Callld 


OrigEndpoint 

(Amedia) 


OrigNAPTAddr 

(Amedia') 


TennNAPTAddr 


TermEndpoint 
(Bmedia') 


987651 


A:0000@0.0.0.0 
. j . , . - 1 


A:4000@192.168.4.4 


A:4000@147.4.4.4 


3300@192.1 68.6.6 



: iowever- the first media portal 44 is still not yet able to perform NAPT translations 
since th ? OrigEr dpoint addless and port are still not known at this point (filled with the 
dummy address). 

1 5 The first media portal 44 then returns (at 446) the terminating NAPT address and port 

in an M<3CP response. The first application server 42 substitutes (in the SDP portion of the 
SIP 200jOK message) the address B me di fl J with B me dia"- The first application server 42 sends 
(at 448) 'the modified SIP 200 OK message to enterprise device A through the firewall and 
NAPT module FNA. The firewall and NAPT module FNA locates the associated mapping 
20 between the assigned external address and port of the enterprise terminal A (A pu biic) and the 
internal address and port (A 1T1 temai) for enterprise device A and substitutes the information in 
the destination address and port fields in the IP and UDP headers of the SIP 200 OK message 
{ with Aimcmai). The modified SIP 200 OK message is sent (at 450) from the 
RT module FNA to the enterprise device A. 
25 Enterprise device A responds (at 452) with a SIP ACK message, which is propagated 

through :he variqus devices back to enterprise device B. At this point, a media session is 
established (at 454) between enterprise device A and enterprise device B through the first and 
second firewall and NAPT modules FNA and the first and second media portal 44 and 45. 
Note that the NAPT mappings in the first and second media portals at this point are still not 
30 fully established. The media portals 44 and 45 await transmission of media packets from 
respective enterprise devices A and B to complete the NAPT mappings. 



(replacing Apubii, 
firewall and Nj 
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Referring to Fig. 6, according to one example after call setup (Fig. 5), enterprise 
device B is the first to send a media packet. The media packet is sent (at 458) from the 

i 

enterprise device B to the second media portal 45 through the firewall and NAPT module 

FNB. The media packet contains the following information: 

IP Header: 

src= 10.5.5.5 

dst =161.6.6.6 

UIXP Header: 

src p'ort = 2000 

dst pjort = 2020 j 

Payload: 

[RTP packet] 

jThe firewall and NAPT module FNB does not have a mapping for the communication 

of media packets, so FNB creates a mapping between the private media source address and 

port BmicdjajniemaJ of the packet and an available external address and port B mC di a . The source 

address' and port Bmediojutemai of the media packet is replaced with the external address and 

port B m Lia> and now contains the following information: 

IP Header: 
src = 61 .3.3.3 
dst= 161.6.6.6 
UDP Header: 
src port = 7070 
dst port = 2020 
Payload: 
[RTIf packet] 

I! ! , 

The modified media packet is sent (at 460) to the second media portal 45. When the 
second media portal 45 receives the packet, the second media portal 45 fills (at 461) the 
TermEndpoint field with the source address and port information B me dia from the media 
packet. The mapping table entry now looks as follows: 



Callld 


i OrigEndpoint 


OrigNAPTAddr 


TermNAPTAddr 

(Bmedia') 


TermEndpoint 


987651 


A:4000@192.168.4.4 


A:2020@l 61.6.6.6 


A:3300@l 92. 168.6.6 


A;7070@61.3.3 



The second media portal 45 consults the mapping table entry and performs a 
substitu ion of both the source and destination network addresses and ports, and sends the 
modified media packet (at 462) to the first media portal 44. 
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however., the NAPT mappinginformation is not fully established in the first media 
portal 4^ for the nedia session between enterprise devices A and B, assuming that a media 
packet h is not be en received yet from enterprise device A. Thus, the first media portal 44 is 
locked (at 464) in this waiting state (discarding packets) until a media packet arrives from 
enterprise device A. 

At some point, enterprise device A sends (at 466) a media packet to the first media 

portal 4^ (through the firewall and NAPT module FNA). The media packet is as follows: 

IP Header: 
sre = 10.1.1.1 
dst= 147.4.4.4 
UDP Header: 
sre port =1000 
dst port = 4000 
Payload: 
[RTP packet] 

' sjince the firewall and NAPT module FNA does not have mappings for the session 
yet, it creates a mapping between the private media source address and port Amediajntemai 
10.1.1.1 JlOOO) for enterprise device A and an available external address and port Amedia- The 
firewall and NAPT module FNA then substitutes the source address and port in the IP and 
UDP headers of the media packet, and sends the modified media packet (at 468) to the first 
media pcjrtal 44. 

When the first media portal 44 receives the media packet from enterprise device A 
(really from the firewall and NAPT module FNA), the media portal 44 now has enough 
information to complete the mapping table entry for the media session. As a result, it 
accesses Ithe OrigEndpoint information and replaces the dummy address 0.0.0.0:0000 with the 
source address and port A me dia of the media packet received from the firewall and NAPT 
module FNA. The mapped table entry in the first media portal 44 now looks as follows: 



CalHd 




OrigEndpoint 


OrigNAPTAddr 

(Amedia ) 


TeimNAPTAddr 

(Bmcdia") 


TermEndpoint 


987651 




A:6060@47.2.2.2 


A:4000@192.1 68.4.4 


A:4000@147.4.4.4 


A:3300@192. 168.6.6 



30 



The first ifredia porta^ 44 then modifies the source and destination network addresses 
and ports of the media packdt and sends (at 470) the media packet through the second media 
portal 45i to enterprise device B. 
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Once the mapping table entry in the first media portal is completed, any packets 
originated by enterprise device B can be forwarded (at 472 and 474) through the firewall and 
NAPT module FNA to enterprise device A. At this point, bi-directional media flows can be 
performed (at 476) between enterprise devices A and B. 
5 The various nodes and systems discussed each includes various software routines or 

modules!. Such software routines or modules are executable on corresponding control units. 

Each control unit includes a microprocessor, a microcontroller, a processor card (including 

i 

one or more microprocessors or microcontrollers), or other control or computing devices. As 
used here, a "controller" refers to a hardware component, software component, or a 
1 0 combination of t le two. Although used in the singular sense, a "controller" can also refer to 
plural hjrdware cjomponenti, plural software components, or a combination thereof. 

The storage devices referred to in this discussion include one or more machine- 
readable' storage media for storing data and instructions. The storage media include different 
forms of memory including semiconductor memory devices such as dynamic or static random 

1 5 access memories (DRAMs or SRAMs), erasable and programmable read-only memories 

i 

(EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and 
flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic 
media including tape; and optical media such as compact disks (CDs) or digital video disks 

i 

(DVDs).j Instructions that make up the various software routines or modules in the various 
20 devices or systenhs are stored in respective storage devices. The instructions when executed 
by a respective control unit cause the corresponding node or system to perform programmed 
acts. 

The instructions of the software routines or modules are loaded or transported to each 
node or system in one of mapy different ways. For example, code segments including 

25 instructions stored on floppy disks, CD or DVD media, a hard disk, or transported through a 
network interface card, modem, or other interface device are loaded into the device or system 
and executed as corresponding software routines or modules. In the loading or transport 
process, pata signals that are embodied in carrier waves (transmitted over telephone lines, 
network iines, wireless links, cables, and the like) communicate the code segments, including 

30 instructions, to the device or system. Such carrier waves are in the form of electrical, optical, 
acoustical, electromagnetic, or other types of signals. 
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While the invention has heen disclosed with respect to a limited number of 
embodiments, those skilled in the art will appreciate numerous modifications and variations 
therefrom. It is juitended that the appended claims cover such modifications and variations as 
fall within the tipe spirit and scope of the invention. 
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What is Claimed is: ! 

1 . A method for use in communications involving a first terminal that is coupled 
to one side of a firewall and network address translator, the method comprising: 

' sending, by the first terminal, a message identifying the first terminal to a node 
on another side of the firewall and network address translator; 

receiving, by the first terminal, another message from the node, wherein the 
messages between the first terminal and the node causes creation of a path through the 
firewall and network address translator; and 

repeatedly sending keep-alive messages to maintain the path through the 
and network address translator. 



firewall 



terminal 
translator, 



1 he method of claim 1 , further comprising receiving a call request, by the first 
, from the node over the path maintained through the firewall and network address 



The method of claim 1, wherein repeatedly sending the keep-alive messages is 



based on a timer in the first terminal. 

i 



The method of claim 1, wherein sending the identifying message comprises 
sending' a registration message to register the first terminal with the node. 



5. The method of claim 4, wherein sending the registration message comprises 



sending 



sending 
the 



Session 



a Session Initiation Protocol REGISTER message. 

r 

I 

The method of claim 5, wherein sending the registration message comprises 

the registration message to a Session Initiation Protocol proxy, the node comprising 

i j 

Initiation Protocol proxy. 



7. 



The method of claim 1, further comprising exchanging messages, by the first 
terminal, with the node over the path maintained through the firewall and network address 
translator to establish a call session. 



•I 
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8. A system for use in communications between a first terminal and a second 
terminal, the first terminal coupled to a remote network address translator, the system 
comprising: 

I a storage module to store network address translation information for the first 



termina 



information during setup of a communications session between the first and second terminals 



session 



; and 



controller adapted to partially create the network address translation 



and to vait for a 



has beer 



media packet originated by the first terminal after the communications 



setup 



to cp: 



I mplete the network address translation information. 



9. The system of claim 8, wherein the media packet contains a source address, 
the source address comprising a public address that is allocated to the first terminal by the 
remote network address translator. 

i 

1 0. The system of claim 9, wherein the public address of the first terminal is 
unknown to the controller until after the media packet has been received. 

1. The system of claim 10, wherein the controller is adapted to further exchange 
control packets with a device containing the remote network address translator to set up the 



device 



communications 



isession between the first and second terminals. 



CO] 



2. The system of claim 11, wherein at least one of the control packets from the 

j ; 

>ntains an identifier to identify a private address of the first terminal that is to be 



used for; communications of media packets. 



1 13. The system of claim 1 2, wherein the controller is adapted to ignore the private 

2 address of the first terminal for communicating media packets between the first and second 

3 terminals. 



1 l|4. The system of claim 11, wherein the control packets comprise Session 

2 initiation Protocol control packets. 
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(l5. Tjlie system of claim 14, wherein the media packet contain Real-Time Protocol 



data: 



16. TThe system 6f claim 14, wherein the media packet contains at least one of the 
following types ! of data: file transfer data, interactive electronic gaming data, and 
whitebriarding data. 



17. The system of claim 8, wherein the network address translation information 
comprises information to map a network address of the first terminal to an alias address of the 
first terminal. 

18. The system of claim 17, wherein the network address translation information 
further comprises information to map a network address of the second terminal to an alias 
address |of the second terminal. 



packets 
the first 



TJhe system of claim 17, wherein the controller is adapted to transmit media 
originated by the first terminal to the second terminal, each media packet containing 
terminal alias address as a source address. 



20. The system of claim 8, wherein the controller comprises plural modules, the 
plural modules comprising a first module adapted to exchange call control signaling and a 
second module adapted to exchange media packets between the first and second terminals. 



21. An article comprising at least one storage medium containing instructions for 
establishing communications between a first terminal and a second terminal, the instructions 
when executed causing a system to perform a method comprising: 



storing network address translation information for the first terminal that 



resides behind a 



communications 



remote network address translator; 



partially creating the network address translation information during setup of a 



session between the first terminal and the second terminal; and 
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waiting for a media packet originated by the first terminal after the 
communications session has been set up to complete the network address translation 

information. 

i 

! 

22. The article of claim 21 , wherein storing the network address translation 
information comprises storing network address translation information containing fields to 
map an address of the first terminal to a first alias address and to map an address of the 
second t ^rminal to a second alias address. 

2 3. Tie article of claim 22, wherein the method further comprises: 

co;rnmunicating, through the system, media packets between the first and 
second t jrminalsj each media packet containing a source address and a destination address; 



and 



translating, for each media packet, both the source and destination addresses. 



24. The article of claim 21, wherein the media packet from the first terminal 
contains; a source address, the source address comprising a public address that is allocated to 
the first terminal by the remote network address translator, the public address of the first 
terminal being unknown to the system until after the media packet has been received. 



25. A-device capable of being used in communications through a firewall and 
network address 'translator, the device comprising: 

an interface adapted to exchange messages with a node on another side of the 
firewall and netviork address translator, the exchange of messages with the node to create a 
path through the Jfirewall and network address translator; and 

a controller adapted to repeatedly send keep-alive messages to maintain the 
path through the firewall and network address translator. 



Jj6. The device of claim 25, further comprising a timer to determine timing of the 



keep-alive messages. 
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